Upgrade to ScienceBeam Trainer DeLFT v1.x (PyTorch) - #695

delft 1.0 picks CUDA whenever torch sees a GPU, where the TensorFlow-era
path was CPU unless configured otherwise. An inference image should not
change device because of the host it lands on.

SCIENCEBEAM_DELFT_DEVICE is the whole mechanism, since Sequence is
constructed here without a device argument. Set as an image default rather
than baked in, so a GPU variant stays possible and an operator can override
it per deployment.

The job installed sciencebeam-trainer-delft outside the lock and ran a
hand-picked subset, because TensorFlow had no arm64 wheels and the delft
extra would not install. Every distribution in that extra now has an
aarch64 wheel, torch included, so arm64 installs like every other platform
and stops being the one job testing an unlocked version.

The selection widens to match macOS: the whole suite minus cv_models. Both
native jobs now also deselect slow, which covers the cases that download
model artifacts - the Docker pytest target runs those.

Upstream measured the conversion's scores, but nothing showed the load path
works in this package's environment, and CI stopped exercising it when the
default profile became wapiti.

The biorxiv_elife header release is the model that exercises conversion and
nothing else: TF-era model_weights.hdf5, and no word embeddings, so it needs
nothing from the embedding registry. Loading the whole profile would be the
wrong shape for CI, since its other models resolve glove-840B.

The case goes through DelftModelImpl rather than the models API. The router
is already covered by mocked tests and the default profile is wapiti, so a
router-level case would need a config override to reach a delft model at
all; the load-and-convert path is what was unproven.

Input comes from HeaderDataGenerator rather than a hand-written feature
matrix, which would risk a width mismatch against the model's config.json
and fail for a reason unrelated to the upgrade. Assertions are shape only -
a pair per token, labels drawn from the model's own set - because asserting
particular labels would re-measure parity here and tie the test to output
upstream has already checked.

Marked slow: it downloads 6.6 MB, so the native jobs deselect it.

The delft extra pulls in torch, and on Linux the default PyPI wheel is the
CUDA build. This project's index configuration is not part of its published
metadata, so it cannot reach a downstream consumer; documentation is the
only mechanism available.

The non-obvious part is not the index block but that torch has to be
declared as a direct dependency for a uv source to apply. A project that
receives torch only through sciencebeam-parser has no binding at all, which
is the same reason the cpu extra keeps its torch line.

Also states that there is no TensorFlow extra and that model URLs need no
change, since TF-era artifacts are converted on load.